Amiga Format CD 24/Amiga Format AFCD24 (Feb 1998, Issue 108).iso/-seriously_amiga-/shareware/programming/amos/transi/lots_of_text.readme

Text File | 1998-01-05 | 33KB | 628 lines

                              ---------------
                              * Transitions *
                              ---------------

  This article and the accompanying  program  were  written by Ragnar Fyri,
who also claims to be the  copyright  holder.  You  may use the routines in
your own (non-commercial) programs on the  condition that you mention some-
where in the program or documentation where they come from, and send Ragnar
a copy. For other use of either the article  or software (either in full or
in part) beyond that it is recommended  that you get in touch first and ob-
tain permission to do whatever it is you  are planning to do. Before you do
it, that is...
  Ragnar Fyri can be contacted  by  email  ([e-mail])  or by
snail mail at

                               Ragnar Fyri
                               Idunns vei 15
                               1370 Asker
                               Norway

  (That's Norway, Europe, not any of the cities by the same name in USA.)

---------------------------------------------------------------------------

                               Introduction
                               ------------

  The subject of this article is, as the  heading suggests, transitions. Or
more precisely, still picture  transitions  programmed  in Amos. To get the
vocabulary straight  first,  a  transition  is  what  happens when you stop
showing one picture and  start  showing  another.  If  you have ever seen a
movie (and who hasn't) :-) you should have seen several transitions, unless
it happened to be "The rope" or some  other  experimental  film done all in
one single shot.
  The thing about transitions is that  they  can  be done in many different
ways, and it is generally a good  idea  to do so. Remember when you used to
visit uncle Harry, and every time you came  around he had the slide projec-
tor set up and wanted to show you all the  pictures he had taken since your
last visit (including those taken  during  that visit)? It was not just the
subject of the show (not to mention  its  length) that was boring, but pic-
tures always appeared by sliding in  from  one side and disappeared by sli-
ding out to the same side. [Which,  presumably,  is why those pictures were
called "slides" in the first place.] It  got slightly better when you star-
ted working and got involved with your  first professional slide show. When
using two projectors it is possible  to  fade  pictures in and out and even
into each other by varying the light  intensity  of  the projectors. Still,
there is only so much that can be  done  when  sending light through static
images on transparent film.
  With computer pictures, however, things start to liven up a bit. When you
have stored pictures in digital form in a computer's RAM there is almost no
end to what you can do with them. There  are even professional presentation
programs (such as Scala) that  can  show  pictures  with all kinds of tran-
sitions, but as a programmer you may  wonder  how  far it is possible to go
with a homemade program. This is the question I will be trying to answer in
the following.

                                  Basics
                                  ------

  The details about how the Amiga  stores  and displays pictures are beyond
the scope of this article, but just to give you a rough idea:
  One great advantage with the Amiga is that  it can handle several screens
at once. With "screen" I do not mean  monitor  or  TV screens (which I will
call displays from now on just to  keep  the concepts apart), but what pro-
fessionals refer to as  screen  structures.  A  screen  (structure) is dis-
tinguished by its size (width,  height  and  number of colours), resolution
(horizontal and vertical) and mode.  For  further details dig out your Amos
manual and read the chapters about  screens  and graphics, and a bit  about
Screen Open, Screen Width, Screen Height, Screen Colours and interlace mode
support. In addition, screens can  have  different palettes. (Check out the
Palette and Colour commands.)
  Basically, there are two ways of making picture transitions on the Amiga.
The first is to replace the image of one  screen with the image of another.
The screens are not really changed,  and  one advantage with this method is
that it does not really matter what size  or resolution the screens are, or
how their palettes  are  defined,  because  they  are  treated  as separate
entities and displayed on different  parts  of  the display - assuming they
are displayed at all; one of the  special  features of Amos is that you can
have "hidden" screens. (Read up on Screen Hide and Screen Show.) The second
way is to replace the contents of  one  screen  structure with those of an-
other (hidden) one, bit by  bit.  This  method  can do more advanced things
than the first, but the disadvantage  is  that for it to work well, the two
screens must be of the same size and  resolution,  and preferably share the
same palette as  well.  [The  pictures  that  come  with  the demonstration
program were specially created to  meet  these requirements, so they can be
used for both methods.]

  The best way to illustrate this article  while you continue reading would
be to run the program and swap  back  and  forth  between Amos and whatever
reader program you are using.  So  now  I  want you to go to the Workbench,
start Amos, locate the demo program,  load  and run it. Then press the Ctrl
key to return to this text (assuming you didn't stop the text reader to use
the Workbench, in which case you have to restart it and reload this text.)
  [By the way, pressing Ctrl is not  the  "normal"  way to swap to and from
Amos, I just added a little routine to make life a bit easier. I hope.]

                       1) Screen swapping transitions
                      -------------------------------

  The simplest way to go from one  picture  to  another is doing what movie
people call a "cut". Before everyone  started  using video, this transition
was made by literally cutting and splicing  film. Go to the teddy bear pic-
ture (by pressing Ctrl again) and type A to see a typical cut.


  As you can see, it's a rather simple effect, and the code for doing it is
simple too:

         Screen to Front UNSEEN

  A little explanation seems in place:  Each  screen  has a unique number -
the ones used in this program are numbered  0 and 1, and numbers can be put
into variables, which is just what I  have  done  here. SEEN is the visible
screen, UNSEEN is the "invisible" one.  After switching them around one way
or another, all that needs to be done to  set up for the next transition is
to swap the two variables around:

         Swap SEEN,UNSEEN

and hey presto - even though the two  screens  now have changed roles, SEEN
still points to the one you see and UNSEEN to the other! This saves you the
trouble of writing two sets of all the routines! :-)

[When two screens occupy the same  coordinates  on the display, only one of
them is visible (unless they are in dual  playfield mode, which is not used
in this program, so just forget about it  for now). When screens are Opened
or Unpacked, they are automatically placed  "in front" of any other screens
that exist at the time. You can control which screen is "in front" with the
commands Screen To Front and Screen  To  Back  (RTFM). The main loop of the
program prepares for each transition  by  unpacking  a new screen {actually
it's the same two screens that  get  reused  over  and over, but for e.g. a
slide show (or perhaps it should be  called  a  transition show now? :) you
would of course load and unpack new  pictures  all  the time} and "Backing"
(to coin a phrase :) it, so  this  routine  makes  it visible by "Fronting"
it.]

                               ----ooOoo----

  That was simple. The easiest way of  livening  it  up a bit is to use the
same technique used in the  professional  slide shows I mentioned some time
back: Fading. Fortunately Amos has a special command for this, and the sim-
plest way to use it is to fade to black:

         Screen SEEN : Fade 5

  The first command here sets screen number SEEN to be active, to make sure
that is the one that gets faded - there  is no point in fading a screen you
can't see anyway! The second  command,  which is the simplest version ofthe
Fade command, then fades all the screen's  colours to black with a delay of
5 between each step. [Amos measures delays and things like that in vertical
blanks, which to the layman is  just  a  fancy  term for how many times per
second the screen is redrawn. PAL machines use 50, NTSC machines 60.]
  One thing that must be remembered when using Fade is that it is an inter-
rupt driven command. During the time it  takes to finish, the program keeps
executing, so if the next command should  be a cut to the unseen screen you
will not see the screen fade out because  the program starts the fade, then
immediately pushes the other screen to the front.
  There are two ways of handling this. The  simplest way is to multiply the
delay by 15 and Waiting for that long. In this case that would be

         Wait 75

  Why 15? some beginners may ask. Because  the number after Fade (5 in this
case) is the delay between each step in  the fade, and a colour may take up
to 15 steps to fade into another.
  A more elegant solution is to find out  which colour has a component fur-
thest from the target, and wait  for  that  colour  to reach its target. In
this program I have been cheating  a  bit  because  I know that colour 1 is
white, which is FFF in hex. So the  fade-to-black  routine simply waits for
colour 1 to become pitch black:

         Repeat : Until Colour(1)=0

  Press B to see the visible screen fade to black and cut to the other pic-
ture.

  Now that could have  been  done  better,  couldn't  it?  Why not fade the
second picture up from black? Sure, Fade can do that too with just one more
parameter and a bit of preparation. Press C to invoke this routine:

         Screen 2 : Get Palette UNSEEN
         Screen UNSEEN
         For A=0 To Screen Colour-1 : Colour A,0 : Next
         Gosub B : Rem Fade to black and cut
         Screen SEEN : Fade 5 To 2
         Repeat : Until Colour(1)=4095

Fading to black is simple, but to  fade  to anything else we need somewhere
to keep the target palette. In  this  program  I  use  screen 2, which is a
small (hidden) dummy screen that was opened  (and hidden away) in the setup
phase. The first this routine  does  is  to  activate screen 2 and copy the
unseen screen's palette to it. A  word  of  caution before we proceed: When
using a screen to grab a different screen's  palette this way it is import-
ant to TURN OFF THE FLASHING. [This was also done in the setup.]
  Now that we have the target palette  in  a safe place, it is time to pre-
pare the new screen for the  transition  by setting all its colours to 0 or
black. Then I save a bit of typing and space by reusing the B routine which
not only fades  the  visible  screen  to  black,  but  also  swaps  the two
variables SEEN and UNSEEN and sets a flag to indicate to the main loop that
a successsful transition was made  (or  in this case, is in progress). Then
the new screen  is  activated  (Remember,  A  swapped  the pointers, so the
Screen SEEN here does exactly the  opposite  of the same command in B! Con-
fused yet?) and faded back to its  old  palette  with Fade 5 To 2, which is
the second version of the Fade command. The last line then waits for colour
1 to become white.

[A little side note: Fade also has a third syntax where you have to specify
each target colour manually, for example

         Fade 25,$F00,$FFF,$F

would fade the first three colours of the active screen very slowly to red,
white and blue (which should awaken some  patriotic feelings in most of the
intended audience :). It is not used in this program because it can be very
complicated to use (well, at least  if  you consider lots of typing compli-
cated). To fade in a 32-colour screen for  example, you would have to first
store the target palette in several  variables  and then run a command like
this one:

         Fade 5,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9,C10,C11,C12,C13,C14,C15,
         C16,C17,C18,C19,C20,C21,C22,C23,C24,C25,C26,C27,C28,C29,30,C31

(only it would have to be on one  line!)  Yes,  you could use an array, but
that would only make the storing part simpler,  you would still have to use
a very long command with 33  parameters  -  as a matter of fact it would be
even longer because of the brackets!  Sure,  it would be great if you could
e.g. "Fade 5,HUES()", but Francois didn't think of that - maybe some future
version of the language...]

                               ----ooOoo----

  Now fading to black is all very well, but  a couple of alternatives would
be fine. Why not do exactly  the  opposite?  Well,  it can't be done with a
slide projector, but you may recall  that  I  said some time back that any-
thing  is possible on a computer. The next routine was originally developed
during the early work on CreAm's slide show Heaven in Hell (or was that the
other way round?) [found on  Aminet  -  look  for crm-hih in the demo/slide
directory]. Our leader, who had probably been watching too many TV2 station
breaks :-), wanted pictures to  change  "with  a white flash", and  I wrote
the routine you can see in action with a press of the D key.

         Screen 2
         For A=0 To 31 : Colour(A),4095 : Next
         Screen SEEN : Fade 1 To 2
         Repeat : Until Colour(0)=4095
         Screen 2 : Get Palette UNSEEN
         Screen UNSEEN : Get Palette SEEN
         Gosub A : Fade 1 To 2
         Repeat : Until Colour(0)=0

  This is more or less the  same  as  the  C  routine,  only it starts with
setting screen 2 to all white (4095 is  FFF in hex), then fades the visible
screen to that palette, waits for colour  0 to become white, and then shuf-
fles the palettes a bit. First the  new  screen palette (which is untouched
so far) is copied into screen 2 (using Get Palette which is like a one step
Fade To without the delay), then it  is  replaced with the one from the old
screen (which is now all white), and  then  the new screen is pushed to the
front and faded back to its original colours (stored in screen 2).

  This routine is faster than the fade-to-black-and-back because our leader
had asked for a white flash, so I  used  the  shortest delay available - 1.
But even that was not fast enough for him  (it's really more of a flaaash),
so I wrote a more intricate routine that "fades" a screen to white and back
in just two steps. Press E (on  the  Amos  screen,  but I shouldn't have to
repeat that any more...)

  This routine requires a little setup that is done before the main loop in
the demo program:

         Dim FARGER(31,2,1) : Global FARGER(),LAYER

An array called FARGER (Norwegian  for  colours)  is dimensioned to contain
the maximum number of colours for two screens  times three (I'll explain in
a moment), then this and a pointer are made global because I'm going to use
them in two procedures. NOTE: This effect  only works with screens 0 and 1,
if you insist on using it  with  other  screens  you must either change the
array's third dimension (1 here) to  the  highest screen number you want to
use or do some fancy manipulation of  the  LAYER pointer whenever it's used
to address the array.

  To take things in logical order, the first routine (which is called twice
- once for each  screen)  simply  fetches  the  colours  from the indicated
screen  and calculates new colours  that  are  halfway between the original
colours and an entirely white palette. It goes like this:

         Procedure FINDCOLOURS[LAYER]
            Screen LAYER : For A=0 To Screen Colour-1
               RGB=Colour(A)
               FARGER(A,0,LAYER)=RGB
               'Time for some arithmetics
               FARGER(A,2,LAYER)=$FFF
               R=RGB and $F00 : G=RGB and $F0 : B=RGB and F
               Add R,$F00 : Add G,$F0 : Add B,$F
               R=R/2 : G=G/2 : B=B/2
               R=R and $F00 : G=G and $F0 : B=B and F
               FARGER(A,1,LAYER)=R+G+B
            Next
         End Proc

What this loop does it first to  store  the original colours into the "bot-
tom" of the array (colour,0,layer), then it stores $FFF (pure white) in the
"top" (color,2,layer). The next five  lines  calculate the "average" or the
top and bottom colours by splitting the  colour value into its three compo-
nents, averaging each with the corresponding  component of white and adding
them together again.
  Actually this part is brand new, the  original  program just averaged the
whole number with  $FFF,  which  produced  some  strange  results. The next
paragraph will try to explain the theory  behind this, if you don't want to
get too involved just skip to the next paragraph.

  A colour definition on the Amiga consists  of three four-bit groups which
for no sane reason that I am aware of are called "nybbles". The high nybble
defines the red component, the middle the green and the low the blue. Which
means that for instance pure blue is  $F  or  15, while pure red is $F00 or
3840 (15 times 256). Because the three nybbles are treated as one number by
anything except for the colour  commands,   you get some weird results when
trying to calculate such things as the  average of two colours. Take bright
red, for instance. The hex value is  F00,  so a bit of brainstorming should
lead to the conclusion that $700  would  be a darker red. But just dividing
3840 by 2 would give 1920, which is $780  - and that's more green than red!
The problem is that 15  divided  by  2  is  really  7  and a half, and when
working with the high or middle  nybble  of  a 12-bit number, that half be-
comes an 8 in the nybble below. This  is  why each nybble is ANDed with its
maximum value above to  eliminate  the  fraction.  [1920  AND 3040 is 1792,
which does produce a nice dark red.]

  Okay, now we have defined the colours that  have to be flicked through in
order to produce a short "flash",  actually  producing the effect should be
easy:

         Procedure FAD[OPP]
            If OPP Then _START=0 Else _START=2
            _SLUTT=2-_START : _STEG=Sgn(_SLUTT-_START)
            For A=_START To _SLUTT Step _STEG
               For B=0 To Screen Colour-1 : Colour B,FARGER(B,A,Screen)
               Next : Wait 3 : Wait Vbl
            Next
         End Proc

The routine  takes  only  one  parameter,  OPP  (Norwegian  for  up), which
determines in which direction the  loop  will  run. Set OPP to True, and it
changes the palette from  original  colours  to  all white, and vice versa.
[The variable names START, SLUTT and STEG  are Norwegian for Start, End and
Step, all of which are reserved keywords in  Amos. Actually this also shows
how you can use variable names  that  otherwise  would  have been parsed as
keywords by preceding them with an  underscore.  So  why didn't I call them
_START, _END and  _STEP?  Good  question,let's  move  on  to something more
interesting!]

                               ----ooOoo----

  I have already mentioned that the  Amiga  can handle more than one screen
structure simultaneously. The new thing  is that it does not just mean sto-
ring two or more screens and  switching  from  one to the other in a jiffy.
You can even display two (or more!) screens at the same time [assuming they
don't cover the same area on the display screen] and display just a part of
a screen as well. The following transitions  show a couple of variations of
this theme. Press F to see how this works:

         Auto View Off
         Screen Display UNSEEN,,,,0
         Auto View On
         Gosub A
         For A=1 To Screen Height
            Screen Display SEEN,,,,A : Wait Vbl
         Next

This routine first tells the graphic circuits to display 0 lines of the new
screen, meaning it won't be visible at all, then switches screen and starts
displaying the new screen one line at a  time. This is also the second time
I use Wait Vbl, which I really should have explained one effect ago. I told
you earlier that a vertical blank is just  a time unit equal to the time it
takes to redraw the screen.  The  truth  is  that THE vertical blank is the
brief period after a screen has been completely  drawn (on the display) and
before it starts getting drawn  again.  [If you want to get real technical,
it's the time the electron  beam  which  draws  the  picture takes to reset
itself back at the top of the screen  after  passing  off the bottom.] Wait
Vbl simply waits for this period to make sure any changes to the screen get
drawn at least once before they are changed  again - a bit like waiting for
your last chicken to hatch before starting to count them.

  This can also be done the other way round. Press G to see this:

         For A=Screen Height To 0 Step -1
            Screen Display SEEN,,,,A : Wait Vbl
         Next
         Gosub A

  Which is not just "the other way round"  because the transition goes from
bottom to top, but also because  while  the previous routine "unfolded" the
new screen after first "folding it up"  completely and putting it up front,
this one "folds up" the old  screen  before  pushing  it to the back. Check
what the manual has to say about the  new  commands  to find out more. (But
then you are doing that all the time, aren't you?)

  But even this is only the beginning. After exposing a screen from the top
and the bottom you may wonder if  it's  possible  to do it from the middle.
The answer is hidden under the H key and looks like this:

         S0=Y Hard(0)
         SH=Screen Height/2
         Auto View Off
         Screen Display UNSEEN,,SH,,0
         Auto View On
         Gosub A
         For A=1 To SH : Screen Display SEEN,,S0+SH-A,,A*2 : Wait Vbl
         Next

  If Screen Display is a new command to you, you may have wondered what all
those commas were good for.  The  answer  is  that the command controls not
just how much of a  screen  is  displayed,  but  where  on the screen it is
displayed as well. This  routine  changes  both  these things with a rather
unusual result. It starts with  displaying  zero lines of the new screen in
the middle of the old, then it pulls  the  top of the screen up at the same
time as pushing the bottom of the visible  part of the screen down twice as
fast (to compensate for the whole screen moving up).

  This routine is different from the previous  in that the image of the new
screen moves across the display. If you  don't like this but want a similar
effect where both screens appear stationary as the new one appears from the
middle of the old, try this variant (key I):

         S0=Y Hard(0)
         SH=Screen Height/2
         Auto View Off
         Screen Display UNSEEN,,SH,,0 : Screen Offset UNSEEN,,SH
         Auto View On
         Gosub A
         For A=1 To SH
            Screen Display SEEN,,S0+SH-A,,A*2
            Screen Offset SEEN,,SH-A
            Wait Vbl
         Next

Another player called Screen Offset  has  entered the field: The Amiga lets
you not only define where  a  screen  is  displayed  and  how much of it is
visible, but which part of it is visible as well!
[Something strange about these two  routines:  the  second seems simpler in
action, but is actually slightly more complicated!]

  This concludes the chapter on what I call screen swapping transitions. If
you have come this far in one  session,  I suggest taking a break and maybe
experimenting a bit with your own  variants  of the different effects. Fade
to red, for instance, or have the new screen roll up from the bottom, or...
If you come up with some  particularly  astonishing effects, you know where
to send them...

                        2) Replacement transitions
                        --------------------------

  Once again, we'll start with something simple - an effect built into Amos
from the beginning.

         Gosub SIMILAR
         Appear UNSEEN To SEEN,133 : OK=True

Because we are now starting on a new  type  of transitions that require the
two screens to have  identical  dimensions,  each  of  the routines in this
chapter will start with a call to  the  subroutine SIMILAR, which checks if
the two screens are you-know-what  and  exits  the program if they are not.
[NOTE: The subroutine does NOT check  if  the palettes are equal - which is
recommended - so be really careful if you decide to replace the graphics.]
  The actual transition is done with  the  Appear command, which copies the
picture from the invisible screen to the  visible one in a rather fancy way
that allegedly can be  varied  infinitely  by  changing the third parameter
(after the comma).  Some  numbers  don't  work  at  all, so read the manual
before starting to experiment with  this.  [Personally  I prefer relatively
fast transitions that don't take  more  than  ten seconds at most, and some
variants of the Appear effect take  much  longer. Some don't even finish at
all!]
  Unless the old teacher who taught me  the  alphabet got it all wrong, the
key to press for this effect should be J.


  Okay, back to the homemade routines, which all work by replacing the con-
tents of the old screen bit by bit  some  way  or another. Press K for this
one:

         Gosub SIMILAR
         W2=SW1/2 : W1=W2-1
         H2=SH1/2 : H1=H2-1
         For A=1 To W2
            Screen Copy UNSEEN,W1,H1,W2,H2 To SEEN,W1,H1 : Wait Vbl
            Dec W1 : Dec H1 : Inc W2 : Inc H2
         Next : OK=True

The variables SW1 and SH1 were set  by  SIMILAR and stand for the width and
height of the old screen, which at this point should be similar to those of
the new screen (SW2 and SH2). The  routine  simply  starts in the middle of
the screen and copies a larger  square  for  each loop until it reaches the
full width of the screen. [It simply assumes  that the width is bigger than
the height - if you some times use  screens  that  are higher than they are
wide you should do some extra checking here.]
  You probably noticed something missing  and something new in the two rou-
tines in this chapter. There is no call  to subroutine A because two of the
things it does are not  needed.  Because  these  and the following routines
copy data from the new screen into  the  old  there is no point in swapping
them around, and so there is no sense in rearranging the pointers (SEEN and
UNSEEN) either. The one thing A does that  still needs to be done is to set
the flag OK to True (to indicate a  successful  transition), and so that is
done "manually" throughout this chapter.

  There are lots of ways to replace  graphic  data; here is another (key L)
that the professionals call a "wipe":

         Gosub SIMILAR
         For A=0 To SW1-1
            Screen Copy UNSEEN,A,0,A+1,SH1 To SEEN,A,0 : Wait Vbl
         Next : OK=True

  This can easily be rewritten  to  wipe  from  the right to the left (just
modify the second line to make a descending loop), or you can get fancy and
wipe from both sides (key M):

         Gosub SIMILAR
         For A=0 To SW1/2 : B=SW1-A
            Screen Copy UNSEEN,A,0,A+1,SH1 To SEEN,A,0
            Screen Copy UNSEEN,B,0,B+1,SH1 To SEEN,B,0 : Wait Vbl
         Next : OK=True

  If you want something even fancier, try this variant (key N):

         Gosub SIMILAR
         For A=0 To SW1-4 Step 2 : B=SW1-A-3
            Screen Copy UNSEEN,A,0,A+1,SH1 To SEEN,A,0
            Screen Copy UNSEEN,B,0,B+1,SH1 To SEEN,B,0 : Wait Vbl
         Next : OK=True

  This can also be done vertically (key O):

         Gosub SIMILAR
         For A=0 To SH1-4 Step 2 : B=SH1-A-3
            Screen Copy UNSEEN,0,A,SW1,A+1 To SEEN,0,A
            Screen Copy UNSEEN,0,B,SW1,B+1 To SEEN,0,B : Wait Vbl
         Next : OK=True

[Warning: The last two  routines  need  a  bit more work if you use screens
with odd (1,3,5,7,9) widths or heights. Think about it...]
  Of course ALL wipes (including ones  you  think  up yourself) may be done
both horizontally and vertically,  but  I'll  leave that as an exercise for
you and try something different instead.  Like the "flashover" routine this
comes in two parts. The first part is set up before the main loop:

         XER=Screen Width/16 : YER=Screen Height/16 : XYER=(XER*YER)-1
         Dim X(XYER),Y(XYER)
         X=0 : Y=0 : For A=0 To XYER
            X(A)=X : Y(A)=Y
            Add X,1,0 To XER-1 : If X=0 : Inc Y : End If
         Next
         For SHUFFLE=1 To 5
            For A=0 To XYER
               Repeat
                  B=Rnd(XYER)
               Until B<>A
               Swap X(A),X(B) : Swap Y(A),Y(B)
            Next
         Next

Note: This is done after the initial screens unpack to get the right dimen-
sions (Screen Width and  Screen  Height).  What  this does is to divide the
screen into a grid of squares and store  each square's relative coordinates
(the first square is 0,0, the second  is  1,0  and so on) in an array, then
shuffle that array a couple of  times.  All  is them ready for calling this
little routine at the press of the P key:

         For A=0 To XYER
            X1=X(A)*16 : Y1=Y(A)*16 : X2=X1+16 : Y2=Y1+16
            Screen Copy UNSEEN,X1,Y1,X2,Y2 To SEEN,X1,Y1 : Wait Vbl
         Next : OK=True

This goes through the coordinates in the order they ended up after the last
shuffling, translates them to "real" screen coordinates and then copies the
corresponding squares to the visible screen one at a time.
  A little note about this and  any  other  effect  that works with squares
(such as the K effect above):  Remember  that if you use interlace OR hires
(but not both), squares become  rectangles  and  vice versa, so half of the
16s must be replaced with either  8  or  32.  You  can also make the effect
faster or slower by changing the  size  of  the squares. For an experiment,
try stopping the program and replacing all the 16s in the first line of the
setup and the second line of the routine with 32. Run the program, test the
routine and then replace the 32s  with  8s  or even 4s or 2s. Just remember
that the array grows four times bigger every time you halve the size of the
squares, so you may have to put a  Set  Buffer at the start to reserve more
space for variables. (You also need a lot  of patience with size 2 squares!
Size 1 squares don't work with  the  pictures  used  here because there's a
limit to how big an array dimension  can  be, and 320*256 is way above that
limit.) [BTW, one way of  speeding  up  the  routine if you are using small
squares is to leave out  the  Wait  Vbl.  It  still  takes about 45 seconds
though. But I haven't tried compiling it yet...]
  The square effect can also be varied in other ways. For a simple example,
try to delete (or just comment out) the  shuffle loop, and the squares will
be drawn in the order they were first listed. Not very exciting, but by ar-
ranging the coordinates in different  ways  you  can have the change zigzag
up, down,left, right, spiral in our out etc. etc. (This would probably have
to be done with coordinate  data  prepared  manually  and read in from Data
lines or a data file, though.)

  That was actually my last effect, but as  an extra bonus (?) I have added
yet another wipe effect that I  thought  up  while working on this article.
Press Q to see it.

         Gosub SIMILAR
         SEC1=SH1/3 : SEC2=SEC1*2
         For A=0 To SW1-1 : B=SW1-A
            Screen Copy UNSEEN,A,0,A+1,SEC1 To SEEN,A,0
            Screen Copy UNSEEN,B,SEC1,B+1,SEC2 To SEEN,B,SEC1
            Screen Copy UNSEEN,A,SEC2,A+1,SH1-1 To SEEN,A,SEC2
         Next : OK=True

  Of course it can be even more  complicted,  but  this should be enough to
get you started with making more intricate effects on your own.

                              3) A final word
                              ---------------

  I mentioned Scala as an example  of  transition  programs  in  the intro-
duction. While I was working  on  this  article,  Amiga Format released the
program on one of their cover disks.  Assuming  that  "everybody" has it by
now, I came up with a  little  challenge:  Try  to  duplicate ALL the Scala
effects in Amos! Some of them have  already  been done in this article, and
Norwegians have a saying that "Well  started  is  half finished", so with a
bit of joint effort it shouldn't be  that  hard...  [I'm talking about just
the picture transitions and not the  ways  text  appears over pictures, but
who knows...?]
===========================================================================
                 e . n . d .   . o . f .   . f . i . l . e